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Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


This memo is targeted towards the EDI community that is unfamiliar 
with the Internet, including EDI software developers, users, and 
service providers. The memo introduces the Internet and assumes a 
basic knowledge of EDI. 
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1. Introduction 
1.1. What is this document 


This document is informational in nature and attempts to answer 
frequently asked questions concerning the use of the Internet for 
Electronic Data Interchange (EDI). The primary audience is the EDI 
community that is unfamiliar with the Internet, including software 
developers, users, and service providers. The reader needs some 
understanding of EDI. Informational RFCs are prepared by the 
Internet Engineering Task Force (IETF) to improve understanding and 
effectiveness in the use of the Internet. 


1.2. What do you mean by electronic data interchange (EDI) ? 
Except as noted, the document refers to EDI as the use of the 


1) X12 standard developed by the ANSI Accredited Standards 
Committee X12 or 


2) EDIFACT[1] standard United Nations Economic Commission for 
Europe (UN/ECE), Working Party for the Facilitation of 
International Trade Procedures (WP.4). 


The differences between these standards is beyond the scope of this 
FAQ. Both standards activities are managed in the US by: 


Data Interchange Standards Association, Inc, 
1800 Diagonal Road, Suite 200 

Alexandria, Virginia, 22314-2852 

Voice: 703-548-7005 

FAX: 703-548-5738 


There are numerous other standards one could use for EDI, but 
discussion of them is not in the scope of this document. 


1.3. What are the X12 Standards that I should be aware of ? 
ACCREDITED STANDARDS COMMITTEE (ASC) X12 Standards are available from 
DISA at the address specified in Question 1. The following is a good 
starting set of X12 standards. 


1. ASC X12S/94-172, An Introduction to Electronic 
Data Interchange, DISA 1994 Publications Catalog 
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2. ASC X12.3 Data Element Dictionary 
3. ASC X12.5 Interchange Control Structure 
4. ASC X12.6 Application Control Structure 
5. ASC X12.22 Segment Directory 
6. ASC X12.58 Security Structures 

1.4. To whom do I send comments and suggestions ? 


Readers are invited to add questions; please include an answer if you 
know or want to suggest one. Of course corrections and comments are 
welcome; send them to the IETF-EDI mail list by subscribing as 
described in question 7.6. Or a send your comment to 
houser.walt@forum.va.gov. 


1.5. How can I get a copy of this document? 
Request for Comments documents (RFC) are available by anonymous FTP. 
Login with the username "anonymous" and a password of your e-mail 
address. After logging in, type "cd rfc" and then 
"get rfcl865.txt". 
A Web address for the RFC is: 


ftp://ds.internic.net/rfc/rfc1865.txt 


RFC directories are located at: 


o Africa at: ftp.is.co.za (196.4.160.2) 

o Europe: nic.nordu.net (192.36.148.17) 

o Pacific Rim: munnari.oz.au (128.250.1.21) 

o US East Coast: ds.internic.net (198.49.45.10) 

o US West Coast: ftp.isi.edu (128.9.0.32) 
RFCs are also available by mail. Send a message to: 


mailserv@ds.internic.net. In the body type: 


"PILE /rfc/rfcl1865.txt" 


NOTE: The mail server at ds.internic.net can return the document in 
MIME-encoded form by using the "mpack" utility. To use this feature, 
insert the command "ENCODING mime" before the "FILE" command. To 
decode the response(s), you will need "munpack" or a MIME-compliant 
mail reader. Different MIME-compliant mail readers exhibit different 
behavior, especially when dealing with "multipart" MIME messages 
(i.e., documents which have been split up into multiple messages), so 
check your local documentation on how to manipulate these messages. 
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2. General Information 
2.1. What is the Internet ? 


It is the inter-working of existing corporate and government networks 
using commonly used telecommunications standards. It is not a new 
physical network, although some new facilities may be needed. 

Rather, it is based on mutual interests of users to communicate more 
effectively via electronic message and file transfers. Internet 
communications may be interpersonal (person-to-person) E-Mail or 
process-to-process like EDI. Messages may be inquiries to shared 
databases and responses. Messages may be entire files. 


22s Is there a difference between EDI and electronic commerce (EC) ? 


Electronic Data Interchange (EDI) is defined as the inter-process 
(computer application to computer application) communication of 
business information in a standardized electronic form. Electronic 
Commerce includes EDI, but recognizes the need for inter-personal 
(human to human) communications, the transfer of moneys, and the 
sharing of common data bases as additional activities that aid in the 
efficient conduct of business. By incorporating a wide range of 
technologies, EC is much broader than EDI. However, the focus of 
this document in on EDI, not electronic commerce. 


2.3. What makes the Internet useful for EDI ? 
The greatest benefits will derive from: 

o Adoption of common standards and proven inter-operable systems, 

o Adoption and deployment of a distributed Directory Service 
capability, so that one can readily contact electronically any 
other organization in the world. 

o Explicit commitment by participating organizations to 
cooperatively route traffic, work to resolve addresses, and 


meet required standards. 


o Ubiquitous network coverage from many service providers. This 
allows the customer to choose the level of service needed. 


o Layering of applications (such as EDI) over existing, proven, 
applications. 


o A standards process with reference implementations which 
all vendors have equal access. (a.k.a. a level playing field). 
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o Widely available public domain software including but not 
limited to applications, protocol/transports and multiple 
platform development tools. 


2.4. Does this means we will now have to coordinate our EC/EDI 
activities with the Internet? 


The Internet is not an organization or government agency. You use 
the Internet to do business like you would use the telephone. The 
same Internet connection your organization uses to send electronic 
mail would be the one you use to send EDI transactions. Software 
developers write EDI translators, packages or templates for your e- 
mail system so that you can handle your own EDI transactions. Your 
EDI activities do not need to be coordinated, but your connection to 
the Internet does. 


2.5. How do I find the addresses of other Trading partners on the 
Internet if I don’t have to coordinate my EDI activities with 
a central organization or VAN? 


The Internet works by assigning names or "domains" to 
networks/companies/machines. This is called the Domain Name Service 
(DNS). It works from a distributed tree structure. The Internet 
requires registration of your Internet Protocol (IP) address and 
Domain Name in the Domain Name Service (DNS). Your internet service 
provider can do this for you or assist you in contacting the right 
people to get your assigned addresses and domain names. 


2.6. How fast is the Internet? 


For a modest amount of data with a dedicated connection, a message 
transmission would occur in a matter of seconds, unless the ISP 
selected one of the trading partners is overloaded. The maximum 
delay over the internet backbones is at most a few seconds. Like the 
interstate highway system, speed depends on how close you and your 
trading partner are to Internet backbones. Unfortunately, some areas 
may lack the capacity or "bandwidth" to handle the workload your 
organization requires. Contact your local Internet Service Provider 
for details on service in your area. Also, the more you are willing 
to spend, the better the service. The Internet is inexpensive, but 
(contrary to popular mythology) it is not free. 


2.7. What about reliability of the Internet? 


For high reliability mission critical applications, redundant ISPs 
may be used (with separate backbones), and redundant mail servers at 
separate locations can be used. A single internet email or server 
address can be used to transparently route to any of the redundant 
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servers or network connections. 


If a dedicated Internet connection is used to transmit information, 
e.g., via SMTP (see questions 3.2 and 3.5), then the message is 
delivered directly to the trading partner’s system and delivery is 
assured. If a part time store and forward connection is used, then 
the integrity of the message depends on the ISP or other computers 
used in the forwarding of a message. 


2.8. What are RFCs and where can I get them ? 


RFC stands for Request For Comments. The RFC series of notes covers 
a broad range of topics related to computer communications. The core 
topics are the Internet and the TCP/IP protocol suite. There are 
three categories of RFCs today, Standards Track, Informational, or 
Experimental. Many of the RFCs describe de-facto standards in the 
Internet Community. Copies of RFCs are often posted to the USENET 
newsgroup comp.doc and obtainable from archive sites such as 
ds.internic.net. 


ftp://ds.internic.net/rfc/ 
2.9. Where can I get general information about the Internet? 


Your local bookstore probably has one of the many recent introductory 
publications on the Internet. In addition, look for (or have someone 
get you) the following bibliographies for free: 


RFC 1175 
Bowers, K., LaQuey, T., Reynolds, J., Roubicek, K., 
Stahl, M., and A. Yuan, "FYI on Where to Start - 
A Bibliography of Internetworking Information", 
08/16/1990 (FYI 3) 


ftp://ds.internic.net/rfc/rfc1175.txt 


RFC 1463 
Hoffman, E., and L. Jackson, "FYI on Introducing the 
Internet -- A Short Bibliography of Introductory 


Internetworking Readings for the Network Novice", 
05/27/93 (FYI 19) 


ftp://ds.internic.net/rfc/rfcl1463.txt 
The reader may want to look at the Frequently Asked Questions (FAQ) 
document for the newsgroup alt.internet.services. This FAQ, as well 


as all Usenet FAQs, can be retrieved via ftp from rtfm.mit.edu in the 
directory /pub/usenet/news.answers. These FAQs are also available 
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from ftp.sterling.com in the directory /usenet/news.answers. 
3. Getting Connected To The Internet 
3.1. What do I need to get to use the Internet? 


You need to know your existing telecommunications connectivity, 
address resolution, and routing capabilities. Then you need to 
establish and operate an Electronic Mail gateway and/or other 
application gateway, e.g., for the file transfer protocol (FTP). 
Larger organizations may supply their trading partners with the 
TCP/IP software and X12 translator interfaced to E-mail or FTP. 


1996 


3 


aoe 


What software is used to support electronic mail? 


Simple Mail Transfer Protocol (SMTP) Servers 


A dedicated internet connection usually uses SMTP software to send 
and receive messages. The SMTP server may transfer messages to the 
"spool" area for incoming email in the file system, may queue the 

messages for transmission via UUCP, may hold mail in a POP server, 
or may transfer the message to a proprietary email system. 


Unix-to-Unix Copy (UUCP) Servers 
A UUCP server is used to transfer messages when a store and 


forward is used, either between machines within a WAN, or to 
another machine with a dialup link. 


Post Office Protocol (POP) mail Servers 


A POP server holds email which can later be retrieved by a client 
application run by the user, typically on a PC which might not be 
running 24 hours a day. The TCP/IP protocol is used either over a 
LAN or dialup SLIP connection to retrieve messages. 


Mail User Agents (Mail Readers) 


Uses or applications employ client programs to retrieve and 
display email messages from the file system mail spool area, or 
from another server computer using POP or some other proprietary 
protocol (e.g. Microsoft-—Mail). This mail user agent (UA) software 
is also used to compose and send email via a POP server or system 
email. 


The mail user agent may also process attached files using a 
proprietary format within a mail message, using one of the common 
de-facto standards, or using the Multipurpose Internet Mail 
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Extensions (MIME) internet standard. Among other things, MIME 
permits the identification and concatenation of message parts 
(called "body parts") into a single message that can traverse the 
Internet using the SMTP protocol. The Work in Progress, "EDI in 
MIME" provides the necessary standards for MIME compliant user 
agents to identify EDI body parts. A MIME compliant mail reader 
can process the contents of the messages and dispatch data to 
external software. For example, files can be dragged to file 
system directories, images can be displayed, and audio data can be 
played. In the case of EDI, a message formatted according to the 
MIME-EDI specification could be automatically transferred to an 
EDI processing program. 


Automated Mail Processing 


A typical Mail User Agents is an interactive application. However 
there are automated email message processing programs which can 
sort incoming mail, process forms returned by others, or in the 
case of EDI data, transfer the message contents to the EDI system. 
Messages formatted according to the MIME EDI specification can be 
properly recognized by any MIME compliant mail processing program. 


What types of client-server or server-server protocols exist on 
the Internet? 


Internet email is typically used for two party messaging. The FTP, 
gopher, and HTTP protocols allow many users, possibly anonymous, to 
retrieve data from a central source. For example, corporate catalogs 
can be restricted by potential customers. 


a) 


File Transfer Protocol (FTP) 


Companies with existing connectivity to the Internet may use FTP 
to transfer files to one-another or to their VAN. This solution 
employs the same TCP/IP used for SMTP. Furthermore, Internet 
documents such as EDI in MIME Work in Progress are available via 
FTP on the FTP server "ds.internic.net." 


gopher service protocol. 


Gopher service is a way of organizing selected documents and files 
on an Internet server in a simple tree menu, so that users on 
other Internet computers can find them easily. Most gopher menus 
are also linked to other gopher menus elsewhere, so that users can 
easily jump from one Internet server to another. There are 
thousands of gopher servers in operation worldwide. 
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c) 


The Hypertext Transfer Protocol (HTTP) 


HTTP defines http-server and http-clients that comprise the World 
Wide Web (WWW). WWW was developed by the European Laboratory for 
Particle Physics (CERN) as a tool for exchanging multimedia data 
between researchers. Although there is also no specification for 
graphics in HTTP, most web browsers are graphical in nature. 
Mosaic, available free from the National Center for Supercomputer 
Applications (NCSA), provides a Graphical User Interface (GUI) 
that facilitates user access to information on the Internet. 
Mosaic interprets hypertext based information on the WWW, as well 
as to other linked Index/Directory services such as Archie, FTP, 
Gopher, and X.500 Directory information. Mosaic also supports on 
line Graphic Interchange Format (GIF), Joint Photographic Experts 
Group (JPEG), Motion Picture Experts Group (MPEG), QuickTime, and 
other document, image, and audio types. Vendors have developed 
product catalogues using Mosaic servers. 


WHOIS 


WHOIS servers generally offer information about the organization 
to which they belong. There are many WHOIS servers scattered 
throughout the Internet. To obtain a list of registered WHOIS 
servers, anonymous FTP to rtfm.mit.edu and get the file 
/pub/whois/whois-servers.list. You can: 


fe) run a client program on your own machine to access the 
WHOIS server, 


fe) telnet to a site which hosts the server, eg: telnet to 
whois.internic.net and type help to access the full online 
help 

fe) send an email message to retrieve information from the 
database. eg: send email to mailserv@internic.net with 


a command in the Subject field. Any information in the 
body part of message will be ignored. ie. 


Subject: whois <search string> 


Therefore, to find information on the Internic Registration 
Service, the subject should contain: whois internic 


Moreover, to obtain help information on this service you can 
send two separate email with the following in their subject 
line, respectively: 
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help 
whois help 


3.4. What methods exist to broadcast information across the Internet? 


There are also some usual methods to broadcast messages to multiple 
recipients as described below: 


a) Usenet News 


Usenet news is a cooperative broadcast of messages to all 
participants. Messages are organized into categories called 
newsgroups, and there are over 10,000 newsgroups carried by the 
major ISPs. Individual customers typically subscribe to some 
subset of these which is of interest to the organization. 

Messages are typically held for a week or two, then either 
archived or discarded. Some newsgroups are free form, i.e. anyone 
can post a message, while others are "moderated", i.e. require 
approval prior to posting. 


Though not currently used for any type of EDI, Usenet news could 
be used to broadcast RFQs. For example, comp.newprod is used to 
announce new products, and misc.jobs.wanted is used to announce 
job openings. 


b) Mailing Lists 


If the interest is limited, a mailing list may be used in lieu of 
a newsgroup. These are typically used for discussion groups or 
announcements of a particular nature. Mailing lists are typically 
open, i.e. anyone can "subscribe" by sending an email message to a 
server. For discussion groups, anyone can send a message to the 
server which is then rebroadcast to all subscribers. Since 
Internet email is extremely inexpensive, there is normally no 
charge for use of a mailing list, except for the content of 
e-magazines, etc. Sponsors of an email list typically provide the 
list as a public service. 


For example, a mailing list could be used to broadcast EDI RFQs, 
etc. Vendors might subscribe to various lists related to their 
product or service in order to receive messages sent by potential 
customers. Mailing lists could be provided by large companies for 
internal use, by industry organizations, or VANS. For example, a 
firm or government agency could sponsor various mailing lists for 
EDI RFQ’s, new product announcements, etc. related to procurement. 
The organization could easily allow other potential customers to 
use the same mailing lists to contact vendors. All parties would 
benefit, and the improved access to vendors from an open mailing 
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IIs 


list would more than offset the cost to support the mailing list 
server. Thus service might be available for free. 


What are the ways to connect to the Internet ? 


The following provides a general overview of connectivity options now 
available: 


a) 


Dedicated Connection 


Typically a leased telephone line is used to connect a gateway 
computer or Typically a leased telephone line is used to connect a 
gateway computer or bridge/router of a corporate LAN/WAN to the 
router of the Internet Service Provider's (ISP) Point-Of-Presence 
(POP, not to be confused with the Post Office Protocol). The 
connection may be of various types and speeds, e.g. modem, ISDN, 
DSO, or DS1 line. 


With a dedicated connection, the SMTP protocol is typically used 
to deliver email directly to a trading partners system. Also, 
real-time client server applications can be run directly with a 
trading partners system, including information transferred using 
the FTP and HTTP protocols. 


Some ISPs provide optional services even with dedicated 
connections. For example, store and forward email on an ISP 
server can be used as a backup for a direct SMTP server operated 
by a trading partner. The ISP may offer disk space on their FTP 
and HTTP servers with a high speed connection to the Internet. 
For example, a trading partner might use a 14.4Kb modem for 
dedicated email transfers and use a 1.5Mb connection operated by 
the ISP to distribute FTP and HTTP information. 


On-demand Connection 


An on-demand connection operates like a dedicated connection, 
except a dialup ISDN or modem connection is used. If the link 
remains idle for a certain period of time, the connection is 
dropped. Some ISPs offer dial-out capability so any inbound or 
outbound traffic can reestablish the link. However, many ISPs 
require their customers to dial-in, so only outbound traffic and 
regular polling will establish the link. In the latter case, store 
and forward would likely be used for email, and the ISP servers 
would be used for FTP and HTTP information. 


Houser, et al Informational [Page 13] 


RFC 1865 EDI Meets the Internet January 1996 


c) Part-time Polled Connection 


The Unix-to-Unix Copy (UUCP) protocol is typically used for email, 


news, and (rarely) file transfers. A client organization 
periodically dials the ISP and transfers email and Usenet news for 
the organization, then disconnects. Typically, the client polls 


the ISP at regular intervals, e.g. every 20 minutes, though some 
ISPs dial out when a message is to be delivered. Outgoing email 
can be sent immediately, or queued for transmission with a 
specified maximum delay. 


A UUCP connection may be used to transfer messages to an arbitrary 
number of people or automated mail processing programs. A single 
UUCP connection may also route messages to other systems, e.g. 
divisions within a corporation. UUCP and store-and-forward are 
synonymous. 


Since UUCP is only used to transfer mail and news messages, 
interactive internet client-server applications like FTP and HTTP 
are not available, except using a server provided by an ISP. Thus 
a separate dialup account might be needed to retrieve information 
from other FTP or HTTP servers. UUCP might be used for automated 
email transfer, and a on-demand dialup connection would be used 
for interactive internet client applications. 


Though UUCP accounts imply a delay (up to the polling interval) in 
processing a message, many ISPs allow a customer supplied script 
to process messages immediately on the ISP’s machine. Though UUCP 
can be used to transfer files directly, usually files are 
transferred by encoding them within an email message. 

Transmission within internet email messages is much more widely 
supported and can be gatewayed into proprietary systems. 


d) Dial-up Shell Account 


With a dial-up account, a single user with a personal computer 
running a terminal emulator connects to the ISP’s computer. Mail 
readers, news readers, HTTP browsers, etc. can be run on the ISP 
machine. Data on the ISP machine can be transferred to the 
personal computer manually using a protocol like X-Modem, Z-Modem, 
or Kermit. 


The ISP’s host computer may run one of the usual UNIX command line 
(shell) programs, or may use a custom BBS or other menu driven 
user interface. A proprietary client-server program may be used in 
lieu of a terminal emulator to provide a graphic user interface. 
Some of the proprietary GUI clients provide access to selected 
internet applications, e.g. gopher. 
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A dialup ISP typically has a direct internet connection, however 
very low cost providers might only have a UUCP connection to the 
Internet. Some large proprietary networks such as CompuServe do 
not offer a direct internet connection, and only support UUCP 
email and, sometimes, Usenet news gateways to the Internet. 


d) Personal Serial Line Internet Protocol (SLIP) or Point to Point 
Protocol (PPP) Account 


A SLIP/PPP account is also available as a cross between the on 
demand and dial- up. Like the on-demand account, a single user can 
connect to an ISP and run mail reader, news reader, FTP, HTTP 
browser, etc. client applications directly from a personal 
computer. Unlike the on-demand account, the dial-out computer 
functions as a client only and not a server, and would be used by 
a single user rather than as a gateway to a LAN. 


With a SLIP/PPP account, the POP (Post-Office-Protocol) protocol 
is used for a user’s mail reader client to retrieve messages 
stored in the ISP’s server. Unlike, UUCP, the POP servers hold 
mail for a single user (i.e. individual email address). 


With a SLIP/PPP connection any standard TCP/IP application is tied 
directly into the internet. Thus unlike the proprietary GUI 
software supplied by the ISP, any TCP/IP client application can be 
used. 


A program such as TIA (The Internet Adapter) can be run on a shell 
account which allows a standard UNIX shell account to function as 
a SLIP/PPP account. However, some ISPs do not support TIA as they 
charge extra for SLIP. 


4. Organizational Issues 
4.1. Why is the way we currently do EDI so limiting to its growth? 


There is a tendency for each organization to establish is own rules 
and administrative policies, leading to rising costs of dealing with 
multiple trading partners, each in turn with its own requirements and 
procedures. However, new technologies and business practices are 
necessary if EDI is to move beyond the 30 to 40,000 organizations 
presently using EDI. According to Department of Labor and Internal 
Revenue Service statistics, there are about 6.2 million entities with 
employees and about 14 million other "business" entities. A business 
that wants to sell chairs, for example, would have to check with many 
different customers to see if they had any requirements. By making 
it possible for a business to use a common method to look for 
customers, the barriers entering to the electronic marketplace are 
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greatly eased. This does not mean that there is only one source that 
everyone goes to for a list of current business opportunities. 
Rather, a prospective supplier only needs to go to a single 
electronic marketplace. To communicate with each other, the various 
participants in electronic commerce need to harmonize their 
procedures and processes. Examples include common trading partner 
registration and the adoption of standard implementation conventions 
for EDI messages. 


4.2. My organization has an internal automated system for processing 
requisitions and issuing purchase orders, but it does not create 
the X12 formatted EDI transactions; what should we do ? 


You could enhance your existing system, for example, by adding EDI 
translation software. VANs often offer EDI "translation" 
capabilities that convert flat text files into EDI X12 or EDIFACT 
format. This translation software may be designed with a particular 
technical solution in mind; carefully consider how the software would 
be used and what applications and telecommunications software would 
need to interact with it. You don’t want to inadvertently lock 
yourself into using only one supplier. 


4.3. My organization already has a dial-in bulletin board service 
(BBS) where we post transactions; should we keep it? 


Yes, but that puts you in the role of being your own VAN. By acting 
independently, organizations have established their own dial-up 
electronic bulletin board system with their own unique, but 
functionally equivalent, operating rules. Your BBS will be a little 
different that the next organization’s, making it difficult for 
suppliers to access. By getting transactions from the VANs who 
specialize in moving information, your organization will get the 
widest circulation possible. You will be able to reach trading 
partners you may not even know existed, resulting in more competitive 


bids. Because of their idiosyncratic nature, BBS are not consistent 
with the idea of a "Single face to industry" espoused by the Federal 
Government. 


4.4. My organization currently has a Trading Partner Agreement 
with each trading partner we’re currently doing business with. 
Can we keep them ? 


In the short run you may want to keep some Agreements in place to 
cover unique circumstances. But be careful not to create conflicting 
agreements and directions for your trading partners. Follow the 
procedures common to your particular line of business. In the long 
run, less is better. Hopefully, the introduction of EDI into common 
commercial practice will eliminate the need for EDI-specific 
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agreements. 


4.5. It would be nice to get more trading partners and/or more 
competition, but I’m worried about getting too many transactions 
to be able to handle them. Has this been a problem ? 


The answers to this and related questions presupposes a willingness 
to participate in the open bidding process. While this process is a 
legal requirement for government agencies, many private organizations 
choose not to adopt the practice. The technology of the Internet 
facilitates competition, but the cost of putting these practices in 
place limit their value. This is a business decision, not a 
technical one. Will companies competitively procure critical 
supplies absent a long term relationship with the supplier? For 
essential inputs that will make or break customer satisfaction and 
productivity, the benefits of competition may not be worth the risks. 


Many organizations experience some increase in the number of 
transactions; for competitive procurements, the winning bid should be 
significantly better than those received prior to using the 
electronic system. The impact of an increase in volume needs to be 
evaluated on a situation by situation basis. For example, your 
acquisition support system may need to be re-engineered to quickly 
handle bids by ranking and presenting them to your buyers in low to 
high order. Your new or enhanced system should make it easy to 
receive and reply to any inter-personal messages that are sent and 
linked to a bid (that is, an SMTP/MIME message or the EDI X12.864 
text message transaction set). 


4.6. Does this mean that I’ll receive more messages ? 


There is a strong likelihood the number of messages will increase as 
There is a strong likelihood the number of messages will increase as 
you reach more and more trading partners. After a reasonable trial 
period, your EDI trading partners should be relying on EDI and 
disinclined to use alternative forms of communication that don’t fit 
EDI/EC. Once you use EDI/EC to communicate with a trading partner, 
you should consider discouraging the use of telephone calls or fax 
messages or other non-EDI/EC messages by pointing out the fact that 
telephone or fax messages are processed more slowly. By using 
electronic messaging, you can establish a written and dated audit 
trail. Your application system can route the message to the buyer 
and "attach" it to a "case file". However, if your organization does 
not use automated systems, you will want to adjust your approach to 
dealing with non-EDI messages. 
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4.7. If we see a transaction posted on VAN, how do we respond in 
electronic format ? 


This function is typically handled by applications software, not by 


the Internet. For example, a vendor that wishes to bid on a 
particular Request For Quotation (RFQ) would prepare a bid (X12-843) 
and send it via their VAN of choice. The identification information 


in the interchange control header (ISA) and functional group header 
(GS) will be interpreted by your VAN and forwarded to the buyer’s VAN 
or to the buyer directly, depending on the reply address. VANs may 
reject messages from unregistered sources; otherwise they are 
forwarded to (or otherwise made available to) the buyer. If a buyer 
is using dial-up access to a VAN, then they will have to call-in for 
their messages. 


4.8. My organization has an established bilateral relationship 
(such as an existing contract. Can we send these transaction 
via the Internet ? 


Yes, the Internet can be used to send transaction sets to existing 
trading partners via SMTP or FTP messages. VANs were typically used 
for bilateral relationships between companies, whereas the Internet 
is useful for establishing multilateral relationships. These 
bilateral relationships are usually quite stable, but both parties 
had to agree to share the same VAN or get their VANs to interconnect. 
Multilateral relationships are between organizations that don’t 
necessarily have existing relationships and may be rather ephemeral. 
The Internet is suited to dynamic multilateral relationships that may 
later evolve into static bilateral relationships between companies 


using VANs. Therefore, the issues concerning the Internet (security, 
availability, etc.) are manageable in the early stages of forming a 
relationship. If your current VAN is not capable of using the 


Internet, you may need an alternative route for those messages. 
Later, as the business relationship matures, the use of VANs may be 
appropriate as the level of communication becomes more important. 
For example, unless your system has a directory of all registered 
trading partners, you lack the capabilities to screen and validate 
transactions that arrive at your site. 


5. The Role Of Value Added Networks 
5.1. What is a VAN? 


The use of EDI over the Internet is in the early stages, although the 
technology and services are developing remarkably rapidly. In the 
past, organizations doing EDI typically have relied on specialized 
firms called Value Added Networks (VANs) for technical assistance. 
Many of these organizations will look to their VAN for assistance in 
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using the Internet. VANs specializing in EDI applications provide 
technical support, help desk and troubleshooting for EDI and 
telecommunications problems. They assist in configuration of 
software, upgrades to telecommunications connectivity, data and 
computer security, auditing and tracing of transactions, recovery of 
lost data, service reliability and availability. Some EDI specific 
services can include broadcasting an RFQ to a collection of vendors, 
or storage of EDI information for later search and retrieval. 


5.2. What is an Internet Service Provider (ISP)? 


VAN services have typically used proprietary network or a network 
gatewayed with a specific set of other proprietary networks. In 
contrast an Internet Service Provider (ISP) offers generic network 
access (i.e. not specific to EDI) for all computers connected to the 
internet. A direct internet connection permits real time computer- 
computer communication for client-server applications. 
Alternatively, a part time internet connection can be used to access 
internet servers using an on-demand basis, or access another system 
via email which includes a store and forward method. Internet email 
may be used as a gateway to proprietary networks if the proprietary 
network has an email gateway. 


5.3. How might an ISP be used for EDI? 


Internet email can be configured for a dedicated connection with 
real-time transfers, or a store and forward method (like traditional 
VANS), or a combination of the two, e.g. where a direct delivery to a 
trading partners system is used when a link is operational, anda 
store and forward from an ISP is used as a backup. 


A large organization can connect their network to the Internet at an 
internet exchange point, however, most use a commercial ISP, either a 
major backbone provider, or local resellers of service off one or 
more backbones. The ISP provides technical assistance and access to 
local telecommunications links. 


5.4. Doesn’t EDI presume the services of companies called 
Value Added Networks (VANS) ? 


EDI only specifies a format for business information; the 
transmission of the information is covered under other standards. A 
real world analog is sending a business form from one company to 
another. The "form" could be sent via US mail, US Registered mail, 
via private carrier (UPS/FEDEX) or simply faxed between the 
companies. EDI only requires that the trading partners follow the 
content standards. 
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5.5. If I can use X12 protocol and my VAN to send transactions, 
what is the benefit of using the Internet? 


The Internet E-mail standards have hierarchical address spaces that 
are defined and updated in what the Internet calls "domain name 
servers." Unfortunately, X12 has a flat address space. So, when you 
send an interchange (not via the Internet) to a partner who is ona 
different VAN, your VAN must do a table look up to figure out what 
VAN the receiving party is on. If you use only X12 without the 
Internet, before you can send a message to this partner, you must 
first contact the recipient’s VAN and have them add you as an entry 
to his VAN’s table. If the ISA contained the VAN ID of the 
recipient, then you could (in theory) send interchanges to partners 
via the VAN interconnects without having to notify the recipient’s 
VAN first. However, this theory needs to be worked out in practice. 
In contrast, thanks to the domain name service, Internet e-mail users 
(and Postal users) don’t have to call up their service provider 
before sending a message across an "interconnect" to another service 
provider. 


5.6. Can we expect VANs to offer connections to other VANs via the 
Internet? 


All VANs connected to the Internet are connected to one another, thus 
avoiding most of the problems of interconnecting proprietary 
networks. VANS can then focus on services to their customers such as 
automatic bid submission, market and business opportunity analysis, 
and translation software. 


5.7. How can I use the Internet directly for exchanging EDI messages 
without going through a VAN? 


You and your trading partner must agree on one of the Internet 
protocols for exchanging messages and then agree upon some details 
with the exchange. 


a) Email based messaging 


The simplest and most widely supported means of exchanging 
messages is via internet email. Typically, the IETF-MIME 
encapsulation specification would be used to enclose the EDI 
data within the email message, and the trading partners would 
need to agree upon an encryption method for secure email, 
typically PEM or PGP (see question 8.4). 


The trading partners would then exchange: 
1. The internet email address for EDI messages 
2. An internet email address for personal communications 
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related to EDI 

3. Agreement on the encryption and digital signature 
protocols, including email acknowledgment, e.g. 
support for the "Return-Receipt-To:" email header, 
or X.400 extended email header fields. 

4. Public Keys for PEM or PGP encryption and digital 
signatures. (or private keys for DES encryption) 

5. Agreement on the format of the message, e.g. IETF MIME/EDI. 


A convention for naming email addresses might be 

established, e.g. edi@edi.xyzcorp.com for messages, 
ediinfo@xyzcorp.com for an automated response for human readable 
information on establishing internet EDI, and 
edisupport@xyzcorp.com for a personal contact. 


b) FTP based messaging 


To exchange EDI messages via FTP, some setup information must be 
included in the trading partner agreement. Typically, an account 
would be created for each trading partner for a FTP login, 
including a password. Typically, each X12 or EDIFACT message 

would be stored in a file, and the trading partner agreement would 
define the conventions for naming files and directories for 

the messages. 


The trading partner agreement would include: 

1. FTP login name and password 
Machine(s) from which the login will be accepted 
Additional security protocols, e.g. Kerberos[?] 
Directory and file naming conventions 
File encryption protocols and keys 
Wrappers around EDI data, e.g. MIME/EDI headers, 
PEM/PGP wrappers, etc. 


Oe WN 


There are several compression routines and utilities available for 
virtually any computer system that uses the Internet. Many of these 
utilities will convert across platforms (say UNIX to Mac, UNIX to PC, 
and vise versa) and are available for free from one of several ftp 
archive servers. Use of these compression routines should be used 
with care when one is employing an encryption technique such as PEM 
or PGP. 


5.8. Can the ISA 06 or 08 identify any entity other than the 
‘end’ Trading Partners (i.e. a routing entity) ? 


Yes, although the ISA06 and ISA08 elements are supposed to be used to 


identify the sender and receiver of the interchange, the receiver of 
the interchange could be a clearinghouse (as well as a VAN) that 
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processes the interchange and then forwards the data to the ultimate 
recipient. In this case, you could put the receiver ID of the 
clearinghouse into the ISA08. The clearinghouse would probably have 
to determine the ultimate recipient of the message by looking inside 
the transaction set (or perhaps by using the GS03). Alternatively, 
you could put the receiver ID of the ultimate recipient into the 
ISA08 and the clearinghouse would route the interchange based on the 
ISA08 value (just as a VAN does). 


5.9. Can we specify both the recipient’s address and their VAN 
address in the ISA ? 


There was an X12 DM (data maintenance) request proposed to the X12 
standards committee for a change to the ISA segment (X12 header 
information) that would allow users to specify the recipient’s VAN, 
in addition to the recipient’s ID. The intent was to provide a 
hierarchical address in the ISA. The top level would be the VAN ID, 
and the next level would be the recipient ID. To date, this DM has 
not been approved. 


5.10. Are there other options for routing EDI X12 messages ? 


Yes, the GS02 and GS03 data elements can be used for a second level 
of routing. The GS03 is the application receiver’s code. Some EDI 
users use the GS03 for routing a functional group to a particular 
department or application within the receiver’s corporation. For 
example, you could use the ISA08 to identify the receiver as "Acme 
Corporation" and use the GS03 to identify the receiving application 
as the "Purchasing department (within Acme Corporation)". Many EDI 
users simply put the same value in the ISA06 and the GS02, and put 
the same value in the ISA08 and the GS03. Interestingly, there are 
VANs that will broadcast a message. Other VANs will map the value of 
the ISA08 into a distribution list VAN mailbox ids maintained by the 
VAN. Thus, each recipient receives the exact same copy of the 
interchange and the value of the ISA08 is not changed by the VAN. 


6. US Federal Involvement 
6.1. What is the commitment of the US Federal Government to EDI ? 


In the Federal Information Processing Standard (FIPS) 161-1 for 
Electronic Data Interchange[2], the US Government committed to using 
EDI X12 and EDIFACT standards in the exchange of business information 
with trading partners already using EDI. On October 26, 1993, 
President Clinton signed an Executive memorandum requiring Federal 
agencies to implement the use of electronic commerce in Federal 
purchases as quickly as possible. As the initial step the 
President’s Management Council (PMC) Electronic Commerce Task Force 
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(ECTF), chaired by the Administrator, Office of Federal Procurement 
Policy (OFPP), chartered the Federal Electronic Commerce Acquisition 
Team (ECAT) memorandum. The PMC gave ECAT the task of defining the 
architecture for the government-wide electronic commerce acquisition 
system and identifying the executive departments or agencies 
responsible for developing, implementing, operating, and maintaining 
the Federal electronic system. 


ECAT has become the Federal Electronic Commerce Program Management 
Office (ECA-PMO). The National Institute or Science and Technology 
(NIST) maintains an HTML home page for the ECA-PMO: 


http://snad.ncsl.nist.gov/dartg/edi/fededi.html 
6.2. What is the timetable for the Federal effort ? 


To implement EC and to achieve his objectives for EC, the President 
set forth the following four milestones: 


1) By March 1994, define the architecture for the 
government-wide EC acquisition system and identify 
executive departments or agencies responsible for 
developing, implementing, operating, and maintaining 
the Federal electronic system. The ECAT identified 
the architecture and recommend actions that each agency 
should take. These documents are available via ftp at 
ds.internic.net in the directory /pub/ecat.library. 


ftp://ds.internic.net/pub/ecat.library/ 


2) By September 1994, establish an initial EC capability 
to enable the Federal government and private suppliers 
to exchange standardized requests for quotations (RFQs), 
quotes, purchase orders, and notice of awards and begin 
government-wide implementation. 


3) By July 1995, implement a full-scale Federal EC system 
that expands initial capabilities to include electronic 
payments, document interchange, and supporting data bases. 


4) By January 1997, complete government-wide implementation 
of EC for appropriate Federal purchases, to the maximum 
extent possible. 


6.3. Will the US Government use the Internet to send EDI transactions ? 


According to the ECAT, achieving the following objectives are 
essential for a successful ubiquitous government EDI capability: 
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1) E-mail systems may be used as the transport medium for EDI 
transactions. 


2) FTP, FTAM, SMTP, X.400, or X.400 compatible substitutes 
are the preferable transport methods for EDI. 


3) EDI functionality must be supported such that the user can 
choose between the Internet Protocol Suite (IPS) and Open 
Systems Interconnection (OSI) protocol support. 


4) Directory services will be provided through the X.500 model 
as services become available. 


5) Initial implementation of X.400 shall support the user agent 
services defined in P2 and P22 protocols. 


6) By 1996, the X.400 implementations shall contain the 
services defined in the X.435 specification. 


7) The Internet network may be used for EDI transactions when 
it is capable of providing the essential reliability, 
security, and privacy needed for business transactions. 


6.4. I heard the US Government prohibited commercial use of the 
Internet? 


The Internet contains many Internet Service Providers (ISPs), each 
with its own internal policies governing the conduct of its 
customers. One of the largest ISPs is the National Science 
Foundation. At one time, NSF adopted what is called the Acceptable 
Use Policy of the National Science Foundation (NSF) was intended to 
prevent commercial uses of the original NSF-sponsored Internet 
telecommunications backbone. However, the growing number of 
commercial providers and backbones now part of the Internet have made 
this policy obsolescent. NSF is currently reducing its direct 
support in favor of subsidies to universities and other NSF sponsored 
organizations. Today the US Government is actively encouraging 
commercial uses of the Internet. 


6.5. The US Government is using both Internet and OSI E-mail 
protocols. What should one consider when choosing which to use ? 


For more than a decade, Federal policy has been to promote the Open 
Systems Interconnection (OSI) telecommunications protocols developed 
by international standards bodies. Despite this policy, Government 
agencies, like the private sector, have invested far more in Internet 
than OSI compliant products. Marshall T. Rose’s "The Internet 
Message"[3] compares the two alternative protocol suites and finds 
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clearly in favor of the IPS for messaging in general. For EDI 
specifically, the advantages of the IPS are its simplicity, wide 
availability, and security provided by Privacy Enhanced Mail (PEM, 
see below). IPS lacks a number of desirable features and incurs 
something of an efficiency penalty for binary transfers. On the 
other hand, the OSI standard for messaging handling service (X.400) 
promises a complete solution for EDI; the X.435 protocol includes 
responsibility notifications, X.500 directory support, EDI-specific 
addressing, message store support, message security, and other EDI- 
specific services. Unfortunately, only a handful of X.435 products 
have actually reached the market, their interoperability is not 
assured, and their prices are substantially greater than for their 
IPS counterparts. X.400 addressing tends to lock the customer into 
the domain of the service provider, whereas SMTP/MIME addresses are 
independent of the provider, permitting the customer to take his/her 
business elsewhere relatively easily. The bottom line is that a lot 
more organizations do EDI via the Internet than via OSI. 


6.6. How is the US Government using VANs to distribute business 
opportunities? 


Presently, VANs make EDI request for quotation (RFQ) transactions 
available to their subscribers (along with other services). For 
example, a VAN client may ask that all RFQs for chairs be forwarded 
immediately to them but the client is not interested in being 
notified about RFQs for paper products. When a VAN sends an RFQ to a 
specific client mailbox, the VAN modifies the "to address" to that of 
the client. In this way, a vendor need only subscribe to a VAN that 
is certified to receive and post the RFQs. The vendor then sees a 
single source for all RFQs of interest, regardless of which buying 
organization originated them. The screening and filtering process 
performed by the VANs prevents the spread of electronic "junk" mail. 
However, a trading partner could use an email filtering program to 
filter and sort email, saving on VAN charges. 


6.7. How would use of the Internet for Federal procurement change 
this RFQ process? 


Initially, very few changes may be apparent. New and existing VANs 
will use the Internet to collect and disseminate EDI transactions; 
trading partners may be totally unaware of the change in technology. 
Prices may fall as VANs share telecommunications resources through 
Internet Protocols rather than maintain their own costly proprietary 
telecommunications services. Instead of competing with VANs, the 
ubiquitous connectivity of the Internet offers VANs even greater 
business opportunities. General purpose Internet Service Providers 
(ISPs) do not typically offer EDI specific services, but they can 
provide an alternative means to transfer EDI messages at a small 
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fraction of the cost of typical EDI VANs. 


The impact of an organization’s moving EDI onto the Internet, 
independent of a VAN, is more difficult to assess. In the view of 
some, the introduction of the Internet in the near term (1-5 years) 
adds additional interfaces and complexity to the organization’s 
existing EDI environment. This may in the short term increase costs 
and raise new costs. But a corporate commitment to an open systems 
environment through the use of Internet Protocols offers the 
potential for a greater interoperability, integration of application 
systems, and therefore the promise of higher performance and lower 
costs. Some organizations will be able to get to these benefits 
others will pay for a set of largely incompatible services. The 
return on investment largely depends on one’s ability to consider EDI 
on the Internet as a part of the organization’s overall information 
systems strategy and the organization’s plans for a presence on the 
Internet. 


7. EDI Resources On The Internet 
7.1. Are EDI Standards available on the Internet ? 


The Data Interchange Standards Association (DISA) has a World Wide 
Web server at "http://www.disa.org/"| This Web server has 
considerable information, including a list of new standards, a list 
of all the X12 transaction sets, meeting minutes, calendar of events, 
and lists of courses. Unfortunately, as of this date, the X12 
standards are not available electronically. [soap ...] Hopefully 
that will be added soon. [...soap]. DISA has also set up a gopher 
server (gopher.disa.org) and an FTP server (ftp.disa.org). 


The principle documents regarding ANSI ASC X12’s planned alignment 

with EDIFACT are available on the World Wide Web. The alignment plan 

adopted by a mail ballot of X12 in December 1994/January 1995 is at 
http: /www.disa.org/info/alinplan.html 

The "floor motion" adopted at the X12 meeting in February 1995 is at: 


http:/www.disa.org/meetings/alinmotn.html 


The following mail lists and exploders support X12 and EDIFACT 
standards development work. 
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This is a fully open exploder set up to support X12G. 
To subscribe send an e-mail message to: 
x1l2g-request@snad.ncsl.nist.gov 
The text of the message should only contain the following: 
subscribe xl2g 


After you subscribe, you can broadcast your messages to the 
participants (who have subscribed) via the address 


x1l2g@snad.ncsl.nist.gov. 


This new exploder is concerned with the federal EDI Registry and 

the implementation of IMPDEF within the registry, the EDI Viewers 

and Editors, and the use of IMPDEF to upgrade EDI products. The 

nature of this mailist calls for informal discussion focusing on 

pragmatic issues. 

To subscribe send an e-mail message to: 
fed-reg-request@snad.ncsl.nist.gov 

The text of the message should only contain the following: 

subscribe fed-reg 


Messages intended for the fed-reg list should be sent to: 


fed-reg@snad.ncsl.nist.gov 


This exploder deals with formal discussion in the context of X12 
regarding the evolution of IMPDEF. If would expect that 
discussions in the context of the "fed-reg" exploder result in 
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formal DMRs submitted to "x12c-impdef" and X12C. Anyway, the 
process will be defined and controlled by the appropriate X12C 
authority. 
To subscribe send an e-mail message to: 
x12c-—impdef-request@snad.ncsl.nist.gov 
The text of the message should only contain the following: 
subscribe x12c-impdef 
Messages intended for the fed-reg list should be sent to: 
x12c-impdef@snad.ncsl.nist.gov 
See section 7.7 for additional EDI related mailing lists. 
7.2. Are EDIFACT Standards available on the Internet ? 
You can access the EDIFACT standards via GOPHER from the 
International Telecommunications Union (gopher://info.itu.ch). Here 
are the general directions in getting to the standards. 
Launch the gopher client as gopher info.itu.ch 
Select entry 11 (UN and international organizations) 
Select entry 1 (UN EDITRANS, UN/EDIFACT (EDICORE) ) 


Select entry 3 (UN-EDIFACT Standards Database (EDICORE) ) 
Select entry 1, Publications. 


Owe WNEe 


If you want the actual standards, select 1, Drafts. You will get 


D93A (which becomes the standard S94a) 
D94A (which will be next year’s standard). 


If you want the UNTDED, select 2. If you want the UNTDID, select 3. 
When you get to the lowest level directory in which ever path you 
choose, press D (i.e. upper case D) to download. Choose the protocol 
that suits and you are the proud owner of an EDIFACT Standards 
Directory. 


For electronic mail retrieval, send your message to itudoc@itu.ch 
with no subject and the following message body: 


START 
GET ITU-1900 
END 
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7. 


7. 


Bi 


4. 


The EDI X12 standards are quite complex. How do we decide what 
X12 transactions to implement and how ? 


There are a number of generic implementation conventions (ICs) or 
guidelines; most ICs are prepared on an industry-by-industry basis. 
Be sure that both you and your current trading partners are working 
from the same set. The Federal Electronic Commerce for Acquisition 
Program Management Office has been promoting the 3040 version 
throughout the government and the private sector. Older versions may 
be used in accordance with the ASC X12 rules. Certain ICs are 
published by the Data Interchange Standards Association (DISA); 
contact DISA at the address above for information about ICs for your 
applications. Certain ICs as well as the X12 standards may be 
obtained through: 


Washington Publishing Company 
c/o EDI Support Services 

P.O. Box 203 

Chardon, OH 44024-0203 


US Phone (800) 334-4912 
Non-US Phone (216) 974-7650 
Fax (216) 974-7655 


What Implementation Conventions (ICs) are available over the 
Internet ? 


The US. Federal Implementation Guidelines for Electronic Commerce for 
Acquisition are available for free via FTP at ds.internic.net. These 
cover X12 transaction sets 810, 820, 824, 836, 838, 840, 843, 850, 
855, 864, and 997. The path is pub/ecat.library/fed.ic/xxx where xxx 
can be acrobat.pdf, postscript or ascii file formats. 


ftp://ds.internic.net/pub/ecat.library/fed.ic/ 


The SPEEDE/EXPRESS Project, funded by the National Center for 
Education Statistics of the U.S. Dept. of Ed., publishes an 
Implementation Guide for X12 transaction sets 130, 131, 146, 147, and 
997. The July 1994 versions (each in WordPerfect and in Postscript) 
may be retrieved by anonymous FTP at admissions.carleton.ca. The 
WordPerfect 5.1 files are found in /pub/wp_speede_2 while the 
Postscript files are found in /pub/ps_guide_2. 


ftp://admissions.carleton.ca/pub/wp_speede_2/ 
ftp://admissions.carleton.ca/pub/psguide_2/ 


Complete directions for retrieving these files can be found in the 
AACRAO gopher at AACRAO-DEC.NCHE.EDU. Choose the SPEEDE/ ExPRESS 
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menu item, then Publications, and then select a version of the 
Implementation Guide. Note that guidelines are sometimes referred to 
by the release/version designation (currently 3040). 


The Defense Information Systems Agency (DISA) Center for Standards is 
the designated configuration manager for DoD Electronic 
Commerce/Electronic Data Interchange (EC/EDI) standards. The DoD 
EC/EDI Standards repository system, available via anonymous FTP from 
ftp.sterling.com in the /edi/DoD-edi/ directory, contains DoD EDI ICs 
separated into two categories, User and Test. 


ftp://ftp.sterling.com/edi/DoD-edi/ 


Test conventions are identical to User, except that the condition 
designator for all applicable transaction sets, data segments and 
data elements used by that convention are designated as Mandatory for 
test purposes. Implementation convention files, both user and test 
versions, can be downloaded either individually or all together in 
compressed self-extracting files. All the implementation files are 
available, when decompressed, in both WordPerfect 5.1/5.2 (.WP) file 
format and Standard Exchange Format (SEF) test files which are for 
use with EDISIM software or any other EDI software that conforms with 
the EDISIM .SEF file format. 


The /DoD-edi/2003_User & _Test directories contain draft DoD 
Implementation Conventions based on ANSI X12 Version 2 Release 3 
(2003): 


840 Request for Quotation 

843 Response to Request for Quotation 
850 Purchase Order 

997 Functional Acknowledgement 


The /DoD-edi/3010_User & _Test directories contain draft DoD 
Implementation Conventions based on ANSI X12 Version 3 Release 1 
(3010): 


810 Invoice: 

810 Commercial 

810 Progress Payment 

810 Public Voucher 

840 Request for Quotation 

843 Response to Request for Quotation 
850 Purchase Order 

997 Functional Acknowledgement 


Additional 2003 and 3010 based conventions may be added in the near 
future. 3010 based conventions will never progress to approved 
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status but will be used temporarily by various DoD agencies to 
implement phase I of the DoD Electronic Commerce (EC)/Electronic Data 
Interchange (EDI) in Contracting Report. 


The /DoD-edi/3050_User directory contains draft DoD Implementation 
Conventions based on ANSI X12 Version 3 Release 5 (3050): 


840 Request for Quotation 

843 Response to Request for Quotation 

850 Purchase Order 

855 Purchase Order Acknowledgement 

860 Purchase Order Change Request - Buyer Initiated 

865 Purchase Order Change Acknowledgement/Request - Seller 
Initiated 


Note that the ICs in the /DoD-edi/3050_USER directory were developed 
as a means to express DOD requirements for an ANSI X12 3050 based 
transaction set. They are not approved for implementation. They 
have been submitted to the Federal IC configuration management 
process for adoption throughout the federal government. Since they 
are subject to Federal review and are based upon a standard not yet 
released, changes can be anticipated. (See ECA PMO above) 


7.5 How can a trading partner keep up with all these implementation 
conventions (ICs) and revisions in X12 and EDIFACT? 


The US government is trying to standardize electronic communications 
internally and with it’s 300,000 plus suppliers. This requires 
standardization of the standards process and cross communication 
between programs. The IMPDEF message and the NIST Federal IC 
Registry will place electronic versions of all its ICs on the 
Registry - both full federal ICs and individual agency ICs - so that 
any trading partner can download and use them. In combination with 
message data compliance checking as well, smaller firms should be 
able to get into EDI and start benefitting both themselves and the 
government. 


7.6. Where can I get information on EDI translation software ? 


Several commercial trade magazines publish periodic guides to EDI 
translation software. Under commission by the US Government, the 
Logistics Management Institute (LMI) of McLean, Va. published "A 
Guide to EDI Translation Software, 1994 Edition." The guide 
describes the features and characteristics of EDI software offered by 
more than 60 vendors. Commercial organizations can get copies for 
$20 each by sending a check made out to the Logistics Management 
nstitute. Federal agencies may have up to five free copies by 
sending requests to 
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Logistics Management Institute 
Attn. Library 

2000 Corporate Ridge 

McLean, Virginia, 22102-7805 


You can fax a typed request to the LMI library at (703) 917-7597 or 
send a request to library@lmi.org. Requests for hard copies of the 
Guide must include the requester’s name, organization, address, 
telephone number, and number of copies desired. All requests should 
cite Report IR421RD1. If you have questions about the Guide, you can 
contact the author, Harold Frohman, at (703) 917-7286 or send him an 
Internet message at hfrohman@lmi.org. A somewhat older LMI report 
(1992), but still quite relevant, is EDI Planning and Implementation 
Guide (DL204RD1, August 1992). 


7.7. How do I keep in touch with others pursuing EDI and Electronic 
Commerce on the Internet ? 


There are several EDI related mailing lists on (and off) the 
Internet. Information on subscription follows below. 


The IETF-EDI list has been established as a forum for discussing 
methods of operating EDI transactions over the Internet, and for 
discussing specifications which permit such operation. This list 
is therefore focused on the technology of Internet usage of EDI, 
rather than on more general aspects of EDI technology or use. 
To subscribe, send an e-mail message to: 

LISTSERV@BYU.EDU. 
The text of the message should only contain the following: 


sub ietf-edi <your-name> 


Messages intended for the ietf-edi list should be sent to: 


TETF-EDI@BYU.EDU. 
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The EDI-L list is target towards more general EDI discussions. 
The edi-l mailing list is also gatewayed to the USENET newsgroup 
bit.listserv.edi-l. 


To subscribe, send an e-mail message to: 


listserv@uccvma.ucop.edu 


The text of the message should only contain the following: 
subscribe edi-l <your-name> 
Messages intended for the edi-l list should be sent to: 


EDI-1@uccvma.ucop.edu 


This list complements ietf-edi in the sense that it promotes 
discussion of new approaches to edi and the extension of edi 
beyond its traditional domains. 
To subscribe, send an e-mail message to: 
edi-new-request@tegsun.harvard.edu 
The text of the message should only contain the following: 
subscribe edi-new <your-name> 


Messages intended for the edi-new list should be sent to: 


edi-new@tegsun.harvard.edu 
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The main purpose of this list is for discussions of Educational 
EDI Standards. 


To subscribe, send an e-mail message to: 
listserv@vtvml.cc.vt.edu 
The text of the message should only contain the following: 
SUBSCRIBE SPEEDE-L firstname lastname 
Messages intended for the speede-l list should be sent to: 


speede-l@vtvml.cc.vt.edu 


The main purpose of this list is for UN/EDIFACT users to review 
the work of JTC1/SC30. 


To subscribe, send an e-mail message to: 
majordomo@utu.premenos.com 
The text of the message should only contain the following: 
subscribe open-edi 
Messages intended for the open-edi list should be sent to: 


OPEN-EDI@utu.premenos.com 


The Federal Electronic Commerce for Acquisition Team (ECAT) has 
established an open mail list for those interested in ECAT 
activities. 


Houser, et al Informational [Page 34] 


RFC 1865 EDI Meets the Internet January 1996 


Information sent to the forum address is automatically distributed 
to all forum members. This forum is available 24 hours a day, 7 
days a week. Currently, only ASCII text messages up to 250kb are 
supported. For best results when sending messages to this forum, 
each line should be limited 70 characters followed by a carriage 
return. Also, your name and email address should be included in 
the body of messages sent. 


To subscribe, send an e-mail message to: 
listserv@forums.fed.gov 
The text of the message should only contain the following: 
subscribe ecat firstname lastname 
Messages intended for the ECAT list should be sent to: 
ECAT@forums.fed.gov. 


7.8. Can I get messages that have been previously posted to the EDI 
mailing lists ? 


Yes. Messages that have appeared on the ecat, edi-l, edi-new, fed- 
reg, xl2c-impdef and ietf-edi list are available via FTP from 


ftp://ftp.sterling.com/edi/lists/ 


7.9. I have EDI related material I’d like to make available to the 
Internet community. How do I do that ? 


If you have an existing Internet connected site, you can make the 
information available via FTP or WWW. If you do not wish to go to 
the effort, send mail to Kent Landfield at 


edi-archive@sterling.com 


Sterling Software is making the archive publicly available to the 
community. Anyone who wants to distribute EDI related documents may 
contact Sterling to make your documents publicly available on 
ftp.sterling.com. For example, the Department of Veterans Affairs 
has posted numerous studies and training materials on EDI which are 
available to the public at ftp.sterling.com/edi/va/. 


7.10. Where are EDI Archives on the Internet ? 


Some have been discussed previously while others have not. Here is a 
very incomplete list of sites that archive EDI related material and 
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make that information publicly available. 


ftp://admissions.carleton.ca/pub/ 
ftp://ds.internic.net/ietf/edi/ 
ftp://ds.internic.net/pub/ecat.library/ 
ftp://ftp.sterling.com/edi/ 
ftp://ftp.swin.edu.au/pub/edi/ 
ftp://prospero.isi.edu/pub/papers/security/ 
ftp://turiel.cs.mu.oz.au/pub/edi/ 


o00000 0 


http://snad.ncsl.nist.gov/dartg/edi/fededi.html 
http://waltz.ncsl.nist.gov/ECIF/ecif.html 
http://www.disa.org/ 

http://www.acq.osd.mil/ec/ 
http://www.ietf.cnri.reston.va.us/ 
http://www.premenos.com/standards/EDIStandards.html 


00000 0 


8. Security Considerations 
8.1. What security measures are needed to connect to the Internet ? 


Internet security measures can be placed in two broad categories: 
protecting your system from intruders and protecting the content and 
integrity of your messages. With respect to the latter, EC/EDI 
transactions of nominal value and sensitivity do not require special 
security requirements. However, if the information has any sensitive 
aspects, you will need to take measures discussed below. Competitors 
might intercept your bids and undercut your proposal. Or they could 
monitor your purchases and shipping notices to determine your firm’s 
production capacity. To ensure confidentiality of the message, your 
e-mail system should offer some means of encrypting the message ina 
manner only the intended recipient can read. Trading partners are 
responsible for satisfying existing rules and regulations relating to 
computer security and privacy. For example, bid data received by 
government systems is subject to the appropriate controls. Trading 
partner financial account data is likewise subject to disclosure 
restrictions. To thwart those who might tamper with a message to 
divert delivery by changing the "ship-to" address, digital signatures 
can attest to the integrity of the message. Digital signatures can 
also authenticate messages, preventing pranksters or rivals from 
submitting false orders. 


8.2. How do we go about protecting our system ? 
The weakest link in most systems are people and passwords; your 


current practices for managing both will apply to use of the 
Internet. Steps you can take include: 
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o Obtain, study, implement, and enforce the NIST FIPS (112) on 
passwords. Make the practice of safe computing a condition of 
continued employment and let your staff know it. 


o Conduct a risk assessment as described in Appendix M of the 
Federal Electronic Commerce for Acquisition Team report 
Streamlining Procurement Through Electronic Commerce. This 
documents is available via ftp at ds.internic.net in the 
directory /pub/ecat.library. 


o Apply the recommendations from NIST Special Publication 800-9, 
Good Security Practices for Electronic Commerce, Including 
Electronic Data Interchange as appropriate. 


o Establish necessary internal and external "Firewalls." See 
John Wack and Lisa Carnahan, "Keeping Your Site Comfortably 
Secure: An Introduction to Internet Firewalls," NIST Special 
Publication 800-10, undated. 


o Review RFC 1281[4] Guidelines for the Secure Operation of 
the Internet and RFC 1244 Holbrook and Reynolds "Site Security 
Handbook" 


o Review Cheswick and Bellovin’s "Firewalls and Internet 
Security - Repelling the Wily Hacker," Addison-Wesley [5] 


o Consider implementing active countermeasures in your firewalls. 
See "There Be Dragons" by S. Bellovin, Proceedings of the Third 
Usenix UNIX Security Symposium, September 1992[6]. You can 
contact Bellovin at smb@ulysses.att.com. 


8.3. Is there good publicly available software I can use? 


These are several free, publicly available, security tools one can 
obtain via ftp from one of many good archives. If your company uses 
UNIX systems to connect to the Internet or has UNIX systems connected 
to the Internet get and use the following tools: 


1. The Purdue University COAST - Security Archive (Computer 
Operations, Audit, and Security Tools, run by Gene Spafford) 
is located at coast.cs.purdue.edu and mirrored in a few places, 
including ftp.sterling.com. 

2. COPS available from ftp.cert.org in /pub/tools 

3. TIGER available from net.tamu.edu in pub/ 


These tools are a series of scripts and programs that will alert you 


to many well-know problems and holes in UNIX systems and how to fix 
them. 
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The Computer Emergency Response Team (CERT) at Carnegie Mellon 
University can assist with computer break-ins as well as provide 
notices of security activity on the Internet. The US Department of 
Energy’s Computer Incident Advisory Capability (CIAC), located at 
Lawrence Livermore National Laboratory, can provide assistance at 
ciac@llnl.gov or at 510-422-8193. CIAC offers software and documents 
on their anonymous ftp server at ciac.llnl.gov. Both CERT and CIAC 
are members of the Forum of Incident Response and Security Teams 
(FIRST), a global organization to foster cooperation and coordination 
among computer security teams worldwide. 


8.4. How good are electronic or digital signatures ? Can they be used 
in court ? 


Properly used, these signature systems are better than existing paper 
based authentication and forgery detection technology. You will find 
a clear and concise description of how these signatures work in Gary 

Ratterree’s RIPEM Beginner’s Guide; contact Ratterree at 


grayr@cs.tamu.edu. Other references include: 
ftp://ftp.tis.com/pub/PEM/ for Privacy Enhanced Mail 
ftp://ftp.rsa.com/ for PEM 
ftp net-dist.mit.edu:/pub/PGP for Pretty Good Privacy 
(PGP) 


An "infrastructure" for public keys is not required to use public key 
encryption or digital signatures. In the absence of such an 
infrastructure, the encryption protocol and the public keys would 
need to be exchanged bilaterally, such as part of the trading partner 
agreement. A public key infrastructure would provide a secure means 
to obtain a public key without a need for a manual key exchange. 


But digital techniques will become more convenient with the arrival 
of additional infrastructure and support systems. The US government 
is taking steps to ensure the admissibility in court of such systems. 
We anticipate that the necessary regulatory and legal infrastructure 
will be in place about the same time as the necessary directory and 
certificate services and other supporting systems come on-line. We 
expect to see expansion of several government pilot programs in the 
later half of 1994. NIST recently published a report on the Public 
Key Infrastructure (PKI) and related policy issues; for information 
contact the NIST Computer Security Division at 301-975-2934. 


8.5. Are there other US government standards publications I should 
be aware of? 


Yes. Here is a sample of those you will often hear mentioned. 
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The 


Federal Information Processing Standard (FIPS) Publication 
46-1, Data Encryption Standard, January 1988. 


FIPS Publication 65, Guideline for Automated Data Processing 
Risk Analysis, August 1979. 


FIPS Publication 113, Computer Data Authentication, May 1985. 
FIPS Publication 180, Secure Hash Standard - (SHS), May 1993. 


FIPS Publication 186, Digital Signature Standard - (DSS), 
May 1994. 


NIST Special Publication 800-9, Good Security Practices for 
Electronic Commerce Including Electronic Data Interchange, 
December 1993. 


FIPS standards may be ordered from the 


U.S. Department of Commerce 
National Technical Information Service 
Springfield, VA 22161. 
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